Let’s look at how some real-world systems exemplify CAP trade-offs:

• MongoDB (CP): MongoDB is a popular NoSQL database which, by default, prioritizes consistency. It uses a primary-secondary replication model. Only the primary can accept writes, and if the primary is lost (partitioned away or down), the system elects a new primary. During that failover window, writes are not accepted – a sacrifice of availability to ensure no two primaries exist (consistency). Once a new primary is in place and secondaries are synchronized, the cluster resumes normal operations. This makes MongoDB CP: it won’t give you an outdated answer (it would rather pause), which is good for applications where stale data could be harmful.

• Cassandra (AP): Cassandra is a distributed database that takes the opposite approach. It has no single primary node – any node can accept writes at any time. This yields high availability and scalability. If a partition happens, Cassandra keeps all sides running; writes might conflict, but the system will reconcile them (using timestamps, hinted handoff, repair jobs, etc.) after the fact. Thus, Cassandra is willing to return older data rather than fail a request, embodying an AP system. It provides tunable consistency (you can configure how many replicas must ack a read/write), but the default philosophy is “always be available.” Many large-scale websites use Cassandra for features like user activity feeds, where it’s okay if one replica is briefly behind as long as the service is up.

• ZooKeeper (CP): ZooKeeper is a coordination service often used for configuration management, leader election, and other tasks in distributed applications. It is famously a CP system. ZooKeeper uses an algorithm (Zab) that requires a majority quorum of nodes to operate. If a network split leaves the cluster without a quorum, the minority side will stop functioning (becoming unavailable) to preserve a single consistent state. In other words' ZooKeeper “sacrifices availability in order to achieve consistency and partition tolerance” – if it cannot guarantee the latest state, it simply won’t respond. This makes ZooKeeper ideal for things like distributed locks and config where consistency (everyone agreeing on one leader, for example) is crucial.

• DynamoDB (AP): DynamoDB, a cloud key-value store from Amazon, is built on the principles of Amazon’s Dynamo paper. DynamoDB is designed to scale across multiple data centers and remain available. It replicates data across zones and continues serving even if some replicas or network links fail, favoring availability. By default, reads are eventually consistent (you might read slightly stale data if a partition occurred), though it offers an option for strongly consistent reads within a region. Amazon’s goal with DynamoDB is that operations (especially writes to things like a shopping cart or user preference) should succeed even in the face of outages – they’ll sort out any inconsistencies later.

These examples show that different systems make different trade-offs. There is no free lunch – you pick the two properties that matter most for your use case. Next, we’ll see an important extension to CAP that considers another dimension: latency.